Before we begin a comparison blog post about PostgreSQL, we must first acknowledge that it is one of the most reliable and widely used databases in the history of software. The world owes a debt of gratitude to the open source community that has built and supported this important project for the last 35 years.
In this post, we unpack some of the architectural differences between PostgreSQL and CockroachDB. We’ll point out where the limitations of single server, single instance architecture might pose challenges for modern cloud infrastructure, and how a distributed foundation can be a better solution for your apps and services.
RELATED
What is distributed SQL? The evolution of the database
What makes CockroachDB a different type of scale than PostgreSQL? 
Cloud infrastructure promises easy scale for our apps and services at the push of a button. Whether we need more compute or more storage, these resources have become commodities; however, to take advantage of their seemingly limitless availability, the software we use must use them correctly.
Typically, scale for a PostgreSQL database involves deploying it on the largest instance you can afford. Then, when you near capacity on this instance, you upgrade to bigger compute. While you’ve increased capacity, it’s essentially just vertical scale and you will reach its limit.
Once you’ve maxed out vertical scale, you have to shift to horizontal scale, which means manual sharding. By using a shard key or hash or whatever is right for you, you’ll need to split the database into smaller pieces and run it on multiple different compute instances. There are lots of different ways to shard a database, but ultimately all manual sharding leads to complex implementations, and a fair amount of overhead in actually implementing it (both from an operations point of view, and from a development point of view).
Scaling in CockroachDB is a bit different. It is a built-in capability that, in its most basic form, delivers horizontal scale without any operational overhead. CockroachDB is a distributed SQL database where each node can service both reads and writes across all participating nodes. So, with the simple addition of a new node into a cluster, you scale both storage capacity and transactional capacity.
Also, data is not synchronized among the nodes. Rather, the cluster uses distributed consensus, writing the data in triplicate across several member nodes. No matter where the data lives, every node can access data anywhere in the cluster. All without any operational overhead other than starting a new node in the cluster!
Why do active/passive systems work only to a point?
High availability (HA) is important because it ensures you can access data and that you have backups in the event of a failure. For legacy databases such as PostgreSQL, you will typically obtain HA via deployment of an active/passive topology. In this configuration, you have a primary and a secondary instance of the database, and you’re doing some sort of synchronization between two instances to make sure that they’re in sync. So, when the primary fails, the secondary can come online. And then, when the crisis is resolved, you get the primary back online and you return to the original configuration.
This approach has worked for some time, however, it is wrought with problems. First, the synchronization between primary and secondary can be complex and may be open to alignment issues between the two systems. Second, the time it takes for the secondary to come online after a failure could be substantial and you may lose data or transactions in the process. But what’s really scary is the remediation when two databases have been in production without syncing together. How do you know what’s correct within that data?
RELATED
Migrate Your Database to CockroachDB
Again, CockroachDB naturally delivers high availability and does so without any complex or costly operations. As noted above, data is written in triplicate across several member nodes of the database, so that if an individual node fails, you still have two copies of the data. The database is even smart enough to notice if a replica is missing and will recreate it on another node so it ensures the replicas are complete.
How does a distributed SQL database simplify geographic expansion?
Another way to look at scale is by assessing your ability to expand your presence into new geographies. With a legacy database like PostgreSQL, you will typically accomplish this by setting up a mirrored instance and then run each database in each region separately. You will typically have two active systems to manage and operate. Aligning the data, or collecting it for analysis, will rely on some sort of complex synchronization.
Once again, there's several issues with this approach. Data across the regional database can be in conflict or duplicative. The operational overhead of managing two systems doubles the cost and complexity of managing your overall service. And finally, you’re on the hook for a fully loaded cost of two systems. Basically, it is expensive and complex.
Not only can CockroachDB scale as you add more nodes, but it can also deliver a single logical database across multiple regions and even major geographies. It can also do this while ensuring you have always-consistent (serializable) transactions everywhere. There are even capabilities that also allow you to tie data to a particular geography to ensure low latency access to data no matter where your customers may be.
Is CockroachDB better than PostgreSQL for distributed applications?
Based on these few elementary considerations above, CockroachDB can deliver a better experience for developers and operators because they no longer need to deal with the complexity of scale, resilience, and geographic expansion. It is perfect for both complex global services and a single instance, single region application.
Most importantly, CockroachDB is compatible with PostgreSQL, so that the tools and services you would typically use with PostgreSQL will work with Cockroach. Both deliver a full and feature rich relational database with powerful SQL syntax.
How do you get started with CockroachDB?
Want to try this yourself? You can spin up a free cluster of CockroachDB right now. With a few clicks you will have a simple, scalable, resilient instance of a relational database.
Want to connect with our team to learn more? They'd be happy to tell how dozens of customers have made the switch to CockroachDB and talk through the migration path. Click here to get in touch.
Cassie McAllister is a Staff Product Marketing Manager at Cockroach Labs. Her focus is on vertical marketing and telling customer stories.
